Optical (i.e., transport) networks and the like (e.g., wavelength division multiplexing (WDM), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN), Ethernet, and the like) at various layers are deploying control plane systems and methods. Control plane systems and methods provide automatic allocation of network resources in an end-to-end manner. Exemplary control planes may include Automatically Switched Optical Network (ASON) as defined in G.8080/Y.1304, Architecture for the automatically switched optical network (ASON) (February 2005), the contents of which are herein incorporated by reference; Generalized Multi-Protocol Label Switching (GMPLS) Architecture as defined in Request for Comments (RFC): 3945 (October 2004) and the like, the contents of which are herein incorporated by reference; Optical Signaling and Routing Protocol (OSRP) from Ciena Corporation which is an optical signaling and routing protocol similar to PNNI (Private Network-to-Network Interface) and MPLS; or any other type control plane for controlling network elements at multiple layers, and establishing connections there between. Control plane systems and methods use bandwidth advertisements to notify peer nodes of available link capacity. The bandwidth advertisements exchange information over a dedicated and well known communication channel with peers on opposite ends of the communication link.
External Network-Network Interface (ENNI) is defined in OIF-E-NNI-Sig-02.0 (April 2009) “OIF E-NNI Signaling Specification,” the contents of which are herein incorporated by reference. ENNI is used for multiple vendor networks/domains which do not share individual network topology there between. Abstract link information is flooded between various domains that do not carry enough resource information to allow path validation for inter-domain calls. Further the resource information on abstract links is not updated dynamically. Therefore path validation is not comprehensive for inter domain calls. This can lead to call setup on an invalid path and thus to crank-backs (i.e., failed connection setups) which cannot be avoided. Call-setup also takes a significantly higher time to establish/fail. During this, a particular ENNI link acts a bottleneck for the new connections. It allows connections of bandwidth equaling to its link bandwidth and rejects any new connections.
In ENNI networks, the bandwidth for inter-domain connections within a vendor cloud is defined by way of Abstract Links that are not updated dynamically or flooded across the cloud. Since this bandwidth is practically un-reserved and may be occupied by other connections (including internal network-network interface (I-NNI) connections), this may lead to gradual deviation of available bandwidth within a domain without the other domains coming to know, thereby causing transit/terminating calls to crank-back as they enter this domain. Also the number of concurrent in-progress call setups is limited to only the bandwidth available on the ENNI and unable to take advantage of the fact that few of the concurrent calls may fail eventually leading to spare bandwidth. This is accentuated by the delays involved in end-to-end connection establishment in multi-domain multi-hop ENNI networks. All of the above lead to high rate of crank-backs.
There is currently no bandwidth reservation capability in the networks for ENNI-connections on in control planes which does not involve explicit reservation. Also the current available bandwidth between a pair of ENNI endpoints (Abstract link bandwidth) is not updated dynamically to other Routing Controllers (RCs) in the network. Therefore, all the outside calls landing on a domain would have to crank-back if sufficient bandwidth is not available to establish them. At present, call setup in ENNI links can only support, for example, 32 simultaneous (in-progress or established) Optical channel Data Unit-0 (ODU0) calls on an Optical channel Transport Unit-3 (OTU3) ENNI Link. Suppose there are 32 ODU0 calls going on an OTU3 link and a RESV message has not been received back for any of the call. If the transient node gets 33rd call on this link, this call will be rejected due to non-availability of the resources. But the resources are not yet involved in the call and there is a high chance of failure of the currently progressing calls. Thereby, it ends up losing the opportunity of any of the failed calls releasing bandwidth to setup this call.
Conventionally while checking for availability of resources on an outgoing ENNI link, a node blocks those resources so that other calls are not able to use them. This conventional approach has a drawback, e.g. assume that on outgoing link 32 timeslots are available. Now if the 32 calls are being setup simultaneously (assume each call consume one timeslot), thus timeslots start getting blocked. Let's say that at time t=0, a first call came in and t=10, a last 32nd call came in. Since all the resources get blocked, this transit node cannot handle any further call until some of the resources are freed. On a transit node, each call can have different starting and end point. Assume some of destination endpoints rejected the calls and the rejection message reached the transit node at, e.g., t=50. When this rejection message reached the transit node at t=50 this node unblocked some of the resources and can now take up further calls. So essentially between t=10 and t=50 all the resources get blocked for calls even if some of the calls became eventually unsuccessful.
Current approaches do not take into the account high chance of failure of calls in control plane networks, such as ASON. So it does not effectively utilize all the resources. A better approach is needed with respect to utilization of the resources available on ENNI links.